The JAVA 2 ENTERPRISE EDITION (J2EE) specification defines the ENTERPRISE ARCHIVE (EAR) file as a standard structure for developing and packaging J2EE applications. EARs are useful for application development, in that the application may, for example, include both a Web application (Webapp) and an ENTERPRISE JAVABEAN (EJB), which will be packaged into the EAR. However, while this works well for completed applications, it isn't very convenient for application development.
In a typical application server development environment that uses EARs, a structure similar to that shown in FIG. 1 is often used. As shown in FIG. 1, the directories for the /myapp application include, for example, a /myejb subdirectory, for storing both ejb source files and XML descriptors. Similarly /myapp may include a /webapp directory, for storing JSPs, html files, and images, etc. All of this code is stored in the source control system for use by the developer in building the application.
To deploy the application, a number of steps must be performed, namely compiling the JAVA files, generating any servlets or container classes, and packaging the whole lot in an EAR. The EAR adheres to a format wherein the top level includes an EAR descriptor IMETA-INF/application.xml, and all of the other components are listed underneath. This approach works well when the application has been fully completed and ready for installation in the production environment. However it's less useful for application development.
A problem with the traditional approach is that the developer will have both source files and system-generated output in the same directory. This can be confusing. It's also hard to generate a clean build of the application since it's difficult to delete only the system-generated files. A mechanism that allows application development while maintaining some separation between the user-coded and system-generated files would be useful in addressing these problems.